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1  Productivity  Measures 

Refereed  papers  submitted  but  not  yet  published:  0 
Refereed  papers  published:  1 
Unrefereed  reports  and  articles:  3 

Books  or  parts  thereof  submitted  but  not  yet  published:  1 

Books  or  parts  thereof  published:  0 

Patents  filed  but  not  yet  granted:  0 

Patents  granted:  0 

Invited  presentations:  0 

Honors  received  (fellowships,  technical  society  appointments,  conference 
committee  role,  editorship,  etc):  0 
Prizes  or  awards  received:  0 
Promotions  obtained:  0 

Graduate  students  supported  >=  25%  of  full  time:  1 
Post-docs  supported  >=  25%  of  full  time:  0 
Minorities  supported:  0 
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2  Detailed  Summary  of  Technical  Progess 

Projects  and  Goals 

A  distributed  system  consists  of  multiple  computers  (called  sites)  that  com¬ 
municate  through  a  network.  Distributed  systems  are  typically  subject  to  site 
crashes  and  communication  link  failures.  A  crash  renders  a  site’s  data  tem¬ 
porarily  or  permanently  inaccessible,  while  a  communication  link  failure  causes 
messages  to  be  lost.  A  failure  is  detected  when  a  site  that  has  sent  a  message 
fails  to  receive  a  response  after  a  certain  duration.  The  absence  of  a  response 
may  indicate  that  the  original  message  was  lost,  that  the  reply  was  lost,  that 
the  recipient  has  crashed,  or  simply  that  the  recipient  is  slow  to  respond. 

The  primary  goal  of  the  Avalon  Project  is  to  create  a  set  of  linguistic  con¬ 
structs  designed  to  give  programmers  explicit  control  over  transaction-based 
processing  of  atomic  objects  for  fault-tolerant  applications.  These  constructs 
have  been  implemented  as  extensions  to  C++  and  Common  Lisp.  The  con¬ 
structs  include  new  encapsulation  and  abstraction  mechanisms,  as  well  as  sup¬ 
port  for  concurrency  and  recovery.  The  decision  to  extend  an  existing  language 
rather  than  to  invent  a  new  one  was  based  on  pragmatic  considerations.  We  felt 
we  could  focus  more  effectively  on  the  new  and  interesting  issues  of  reliability 
and  concurrency  if  we  did  not  have  to  redesign  or  reimplement  basic  language 
features,  and  we  felt  that  building  on  top  of  a  widely-used  and  widely-available 
language  would  facilitate  the  use  of  Avalon  outside  our  own  research  group. 

The  Venari  Project  at  CMU  is  interested  in  performing  queries  over  ob¬ 
jects  residing  in  a  distributed  set  of  persistent  repositories.  These  queries  are 
’’content-addressable"  in  the  sense  that  they  are  based  on  the  objects’  seman¬ 
tics.  A  sample  application  would  be  one  where  a  person  at  a  workstation  writes 
a  first-order  predicate  as  a  query  to  retrieve  all  procedures  whose  pre-  and 
post-condition  specification  "satisfy”  the  query,  where  those  procedures  are  in 
a  library  that  lives  at  a  site  remote  from  the  workstation.  Here,  the  objects  are 
the  procedures;  the  repository  is  a  program  module  library;  the  specifications 
represent  the  procedures’  semantics. 


Past  Accomplishments 

Having  completed  out  Avalon/C++  in  previous  years,  this  past  year  were 
worked  on  our  prototype  for  the  Avalon/Common  Lisp  system.  Details  of  the 
system’s  motivation  and  results  follow: 

One  of  the  initial  design  goals  of  the  Avalon  Project  was  to  extend  existing 
languages,  rather  than  invent  new  ones.  In  the  process  of  such  an  extension, 
it  is  important  to  introduce  as  few  new  features  as  possible,  and  design  those 
features  to  combine  well  with  the  base  language’s  idioms  and  model  of  compu¬ 
tation.  In  our  previous  effort,  Avalon/C-i-f,  we  chose  an  object-oriented  design, 
consistent  with  the  C-f~ f  model.  In  Avalon/Common  Lisp,  we  strove  to  extend 
the  language  in  a  similarly  consistent  manner. 

The  most  significant  enhancement  we  made  to  Common  Lisp  was  the  addi¬ 
tion  of  a  new  first-class  data  type,  the  evaluator.  An  evaluator  represents  an 
additional,  non-local,  Common  Lisp  evaluator,  on  which  the  user  can  evaluate 
expressions,  install  procedures,  and  modify  accessible  data.  Evaluators  are  used 
via  two  new  macros,  remote  and  local,  which  direct  the  thread  of  computation 
to  a  different  evaluator. 

Avalon/Common  Lisp  is  built  on  top  of  three  locally-developed  systems, 
CMU  Common  Lisp,  Mach,  and  Camelot,  and  runs  on  IBM-PC/RTs.  CMU 
Common  Lisp  is  one  of  the  first  implementations  of  Common  Lisp,  and  was 
chosen  over  other  Common  Lisp  implementations  for  two  reasons.  Firstly,  it 
is  the  only  available  Common  Lisp  that  runs  on  the  computers  the  Avalon 
Group  had  already  available.  We  also  favored  the  presence  of  the  support  and 
maintenance  the  locally-managed  system  provides. 

Mach[l],  a  Unix-like  operating  system  with  support  for  distributed  computa¬ 
tion,  is  used  to  provide  communication  among  the  various  Avalon  processes,  and 
to  support  process-level  concurrency.  Camelot[2,  3],  a  machine-independent, 
high-performance,  distributed  transaction  facility,  is  used  to  support  the  fault- 
tolerance  and  reliability  we  desire. 

For  more  details  on  Avalon/Common  Lisp  and  our  conclusions,  please  refer 
to  the  enclosed  Technical  Report  [4,  5}  and  group  notes[6,  7],  or  to  last  years 
Fiscal  Year  report. 

A  shift  in  focus  charaterized  my  work  this  year.  The  successor  to  Avalon, 
Venari,  is  more  concerned  with  persistence  of  data  and  the  manipulation  thereof, 
and  I  have  spent  a  large  part  of  the  year  researching  various  other  programming 
languages  featuring  persistent  data  and  other  database  features  as  part  of  their 
computation  models.  I  conducted  a  thorough  literature  search,  and  am  in  the 
process  of  completing  a  survey  report  of  my  findings. 


Future  Goals 


My  future  research  plan  involves  a  shift  in  direction,  away  from  distributed 
computing  and  towards  parallel  computation.  More  specifically,  how  transac¬ 
tions  can  be  used  as  part  of  the  effort  to  introduce  concurrency  into  existing 
programming  languages.  A  more  detailed  sketch  follows: 

With  the  advent  of  multiprocessors  and  supercomputers,  there  has  been 
considerable  effort  to  develop  programming  language  systems  for  these  new 
platforms.  These  systems  have  taken  two  forms:  sequential  languages  with 
optimizing  compilers  that  introduce  concurrency  while  preserving  the  sequential 
semantics,  and  languages  with  explicit  constructs  for  concurrency. 

Both  approaches  have  merits.  The  ’’parallelizing”  languages  benefit  from 
being  compatible  with  existing  programs  (the  so-called  ’’dusty  deck”  problem) 
and  existing  programmers  are  already  familiar  with  the  computation  model 
presented.  Languages  that  offer  explicit  control  over  parallelism  allow  the  pro¬ 
grammer  to  optimize  his  program  to  a  much  finer  degree  than  the  parallelized 
sequential  program. 

Much  of  the  work  in  parallelizing  sequential  programs  has  been  directed  at 
imperative  programming  constructs,  such  as  loops  and  array  processing.  In 
mostly-functional  languages,  such  as  Scheme  or  ML,  imperative  statements  and 
constructs  are  not  as  prevalent.  However,  various  characteristics  of  the  compu¬ 
tation  model  of  such  languages  offer  opportunities  for  the  implicit  introduction 
of  parallelism.  Both  Scheme  and  ML  leave  the  order  of  evaluation  of  function 
call  arguments  unspecified.  As  a  result,  a  parallelizing  compiler  might  choose 
to  evaluate  the  arguments  concurrently.  Another  possible  optimization  is  the 
evaluation  of  the  forms  included  within  a  sequencing  statement  in  parallel. 

One  important  detail  of  this  parallelization  scheme  has  been  omitted.  One 
constraint  on  the  parallelization  of  loop  constructs  in  imperative  languages  is 
that  there  is  no  data  dependency  between  the  various  loop  iterations.  If  a 
data  dependency  exists,  it  is  possible  that  the  concurrent  execution  of  the  loop 
will  produce  a  different  result  than  the  sequential  execution  that  is  being  emu¬ 
lated.  Since  the  implicit  addition  of  concurrency  into  a  program  is  done  only  to 
improve  exectuion  performance,  an  optimizing  compiler  is  forbidden  to  perform 
any  optimization  that  could  alter  the  semantics  of  the  program.  This  restriction 
applies  equally  to  the  functional  optimizations  mentioned  previously. 

Unlike  FORTRAN  arrays,  however,  it  is  not  always  possible  to  conclusively 
determine  whether  two  execution  threads  can  run  independently.  The  compiler, 
forced  to  act  conservatively,  would  therefore  be  unable  to  allow  the  threads 
to  run  simultaneously,  even  if  the  threat  of  interference  is  remote.  In  such 
circumstances,  the  compiler  might  benefit  if  it  could  use  transaction-processing 
technology.  Such  technology  would  support  the  detection  of  data  interference 
at  execution  time,  and  allow  the  thread  of  execution  fall  back  into  a  sequential 
posture,  [not  precise  enough,  and  transactions  introduced  too  rapidly.] 


Another  benefit  incurred  by  the  presence  of  transactions  would  be  the  ability 
to  improve  concurrent  performance  via  of  use  of  speculative  computation.  A 
conditional  statement  can  be  executed  by  first  spawning  off  both  alternatives, 
and  concurrently  evaluating  the  predicate  test.  Once  the  predicate  value  has 
been  determined,  the  system  can  abort  the  appropriate  arm.  Transaction  se¬ 
mantics  would  ensure  that  the  standard  sequential  semantics  of  the  conditional 
statement  would  be  preserved. 

Such  ideas  were  first  introduced  in  the  ParaTran  system. [8] 

Transactions  could  also  be  used  to  solve  some  of  the  problems  present  in 
existing  explicit  parallel  languages.  For  example,  both  Multilisp  [9]  and  Qlisp[10. 
11]  ignore  the  possiblity  of  interference  that  might  result  from  the  concurrent 
execution  of  threads  if  the  computation  relies  on  side-effecting  operations. 
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3  Publications,  Presentations  and  Reports 


Below  are  the  list  of  publications  I  have  been  involved  with  during  the  past  year: 
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4  Research  Transitions  and  DoD  Interactions 

A  number  of  researchers,  in  both  academia  and  industry,  have  expressed  an 
interest  in  our  Avalon/C-H-  work.  Commercial  sites  include  Microsoft,  Texas 
Instruments,  Hewlett  Packard,  and  NCR.  Academic  sites  include  Boston  Uni- 
veristy,  University  of  Massachusetts  -  Amherst,  Concordia  University  (Mon¬ 
treal),  and  University  of  New  South  Wales  (Australia).  (A  more  detailed  list  is 
available  upon  request.) 

Avalon/Common  Lisp  is  more  dependent  on  the  facilities  present  at  our  local 
site,  and  is  thus  not  as  portable. 
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5  Software  and  Hardware  Prototypes 

Avalon/Common  Lisp  is  stable,  but  it  only  a  prototype,  and  thus  has  restricted 
function.  There  are  no  plans  to  continue  development  on  it,  although  work  is 
proceeding  on  a  ML-based  successor. 


